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GTOSS 

GENERALIZED TETHERED OBJECT SIMULATION SYSTEM 


R. PURPOSE fl£ SIMULATION 


The GTOSS software system consists of approximately 410 subroutines representing 
40,000 lines contained in 120 files. Code is constrained to a highly portable subset of 
Fortran 77, with over 700 pages of documentation describing user operation, 
equation derivation, and system software design. GTOSS runs on most computers 
(including: the Macintosh and PC's). GTOSS has been developed under the direction 
of the Avionics Systems Division, Johnson Space Center, NASA. 

GTOSS represents a tether analysis-complex best described by addressing its family 
of modules, designed to be more or less tightly associated as a cooperative whole. 


Tether dynamics: TOSS 


TOSS is a portable software sub-system specifically designed to be introduced into 
the environment of any existing vehicle dynamics simulation to add the capability 
of simulating multiple interacting objects (via multiple tethers). These objects may 
interact with each other as well as with the vehicle into whose environment TOSS 
has been introduced. TOSS is incorporated by adherence to a straightforward set 
of interface rules set forth in the TOSS Interface Control Document. Without small 
motion assumption, and with complete generality, TOSS solves the tether dynamics 
problem relative to a reference point state defined for it by the host simulation. 

Input is designed for easy data identification and entry, as well as to expedite 
parametric studies. Extensive initialization options (such as stabilized gravity 
gradient start-up, Euler angle type selection, etc.) allow user-friendly run setup. 


General tethered system anelysis: GTOSS 

GTOSS is a stand-alone tethered system analysis program, representing an 
example of TOSS having been married to a host simulation. In order to verify the 
TOSS design concept and exercise the TOSS ICD ground rules, it was necessary to 
create a fully representative, yet easily managed simulation into whose 
environment TOSS could be incorporated. The resulting union was called GTOSS 
and has the properties of, and can be viewed as, a system tailored to the 
purpose of examining dynamic behavior of general tethered object 

configurations (space stations, constellations, etc). By contrast, TOSS has also 
been integrated into a Shuttle simulation (to study TSS), with the resulting 
association exhibiting (and rightfully so) the complexity and specificity of an 
Orblter vehicle. The GTOSS host simulation represents a 6 DOF object with 8 
tether attachment points. GTOSS has an executable code size of about 350k Bytes. 


75 


PHECEDING PAGE BLANK NOT FILMED 


Input and Initialization for GTOSS (as an entity separate from TOSS) is similar to 
that of TOSS. GTOSS provides output for itself as well as TOSS by invoking 
RTOSS (see below) to generate a Results Data Base to archive solution results for 
display post processing. 


Solution-result archiving: RTOSS 

RTOSS is the Results Data Base (SDB) Sub-system designed to archive TOSS 
simulation results for future display processing. While RTOSS was designed 
primarily to capture TOSS data, it offers a Wild-Card file which can be used by any 
users to capture data of their choice. For instance, GTOSS takes advantage of this 
feature to capture its host simulation data to an RDB for display post processing. 
The modular design of RTOSS requires minimal calls (from the host simulation) to 
invoke the creation and population of an RDB (for instance in GTOSS, this act is 
transparent to the user). At the end of a run, a set of files with unique names will 
have been created containing all pertinent time history data. 

Also inherent in RTOSS are the routines which will extract data from the RDB and 
present it in a form most natural for display post- processing. These extraction 
routines insulate the user from structural knowledge of the RDB, thus rendering 
the user's display software invariant to future changes in RDB design. The RDB can 
be post- processed in a miriad of ways for engineering interpretation, as described 
below. 


Simulation result display: DTOSS 

DTOSS is the first of a growing family of display post processors designed to 
effectively utilize the RDB. DTOSS extracts data from the RDB for extensive 
multi-page printed time history displays. There are currently over 50 different 
display formats to choose from, each of which aggregates data selected to meet 
various display needs. Users are also invited to add new page formats to create 
output for specific needs. 


Simulation result display: CTOSS 

CTOSS is similar to DTOSS, but is designed to create ASCII plot files (as headers and 
data columns separated by delimiters). The same time history data formats 
provided by DTOSS (for printing) are available via CTOSS for plotting. In addition to 
time histories, repetitive tether shape snapshots can be taken in CTOSS. While the 
plot files are optimally configured for existing interactive graphics programs on the 
Macintosh computer, their plot format can be used on other PC's. Since CTOSS 
generates ASCII plot files (which are easily transported between different 
computers), it can be run on any mainframe to generate plot files for a PC or 
Macintosh. 
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Simulation result display: ITOSS 

ITOSS differs from DTOSS and CTOSS in two ways. First, it generates output 
display data designed for 3-D animated graphics display of simulation results. 
Second, its output is targetted specifically for the IMI graphics device (a large, high 
resolution, fast display device) . 


Simulation result display: 6ENERRL 


The above RDB post-processors not only represent a significant existing display 
capability for GTOSS, but also function as convenient templates to spawn specialized 
display processors. For instance, hooks are clearly defined, and steps are 
documented to modify the existing DTOSS or CTOSS to add new formats. These 
programs can also serve as a functional boilerplate structure for extracting RDB 
data to be post processed in any fashion you wish. 


B. COORDINATE SYSTEMS flflU DEGREES of FREEDOM 
Coordinate Systems 

The following coordinate systems are used in TOSS: 

A TOSS Inertial Frame The user is allowed to arbitrarily define this frame ; 
however, its relationship to the planet-fixed frame must be explicitly stated in 
the standard TOSS routine invoked to transform inertial frame vector 
components to the planet-fixed frame. This routine (and its inverse- routine) can 
describe an arbitrarily complex relationship between inertial and planet-fixed 
frames. As delivered, the TOSS inertial frame is defined as one which is aligned 
with the planet-fixed frame at zero simulation time. 

B. Planet-fixed Frame. This is typically an earth-fixed frame, and also the one in 
which all planetary environment calculations are defined. The user is allowed to 
arbitrarily define this frame, however, its relationship to the inertial frame 
must be explicitly stated in the TOSS routine which transforms planet frame 
vector components to the inertial frame, and environment calculations must be 
consistent with its definition. As delivered, GTOSS environment routines assume 
an earth- fixed frame, the +X axis of which is presumed to pass through the 
Greenwich meridian, +Z axis through the geocentric North pole. 

C. Topocentric Frame. This is a frame aligned along local spherical longitude, 
latitude, and radius vector to the planet center It is used for state initialization 
options and result interpretation. 

D. Orbital Frame. This frame is defined by the kinematic state of a point, and is 
similar to the topocentric frame except the local longitude/latitude vectors are 
aligned to the current plane of Keplerian motion. Any TOSS entity can have an 
associated orbital frame, which is used for state initialization options and result 
interpretation. 
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E. Body Axis Frame. A body-fixed frame (and a body station reference point) is 
associated with each 6 DOF object. The frame and body station are arbitrary, 
but must be consistently used for defining all body attributes (CG location; 
tether attach-points; aerodynamic reference point, etc). This frame is the 
reference for body attitude interpretation. 

F. Tether Frame. Each finite tether has its own tether frame. The X axis of this 
frame is aligned along the line of sight between the tether's attach points. The Z 
axis is orthogonal to the first, but lies in the orbital plane (of a preferred 
kinematic point). The Y axis is defined to complete the triad. This frame hosts 
the tether dynamics coordinate solution, and is used for both initialization 
options and result interpretation. 


Degrees of Freedom (DOF) 

Many of the DOF are modifiable via procedures included in the manuals The 
nominally delivered GTOSS configuration provides: 

1, Up to 9 bodies (each with up to 6 rigid- body DOF's). 

2. A 3 DOF particle dynamics option to eliminate rotational dynamics overhead 
(for efficient study of overall topological behavior). 

3 Concurrent simulation of up to 25 different tethers. 

4. Tether inter-connection in any conceivable fashion at up to 8 attach-points 
per body. Each attach point is specified by its coordinates in an arbitrary 
body axis frame 

5 No practical constraints on tether/attach point connectivity. 

6 Tether dynamics simulation as your mixed choice of 

• Massless models (ie. linear springs and dash pots) 

• Modal Synthesis finite models (on a tether-by-tether, and axis-by-axis 
basis, up to 15 modal coordinates per each of 3 axes, with the 
evaluative resolution of each generalized force type specifiable at up to a 
maximum of 30 uniform spatial intervals). Tension is optionally 
evaluated either in terms of material strain, or Lagrangian multipliers 

• Point Synthesis (ie. Bead) type finite models (on a tether- by- tether 
basis, up to 48 collocation points per tether; with 3 DOF per point). 
Tether can break on tension limits, or be severed at multiple points. 

7. Five length-rate, and five tension-profile, data-driven deployment scenarios: 

8. Five power-profile (amp-limited} data-driven, power generation scenarios: 

• All deployment and power scenarios can be arbitrarily assigned to any 
one or more tethers (a tether also has its own scenario scaling factors). 
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C. ENUIBONMENTRL MODELS 

Planetary Enulronmant 


Subroutine calls to the planetary environment models are standardized within TOSS 
so that any level of environmental sophistication (you have available) can be easily 
incorporated into TOSS. Calling arguments to an environment model are: a 
sophistication-level flag; and, a position state in the planet-fixed (earth) frame. 
Vector results are returned in the planet-fixed frame. Currently delivered with 
GTOSS are the following: 

o Gravitational Field Model: Earth; Inverse square central force field, also an 
Oblateness model with 2 anomaly terms. 

o Globe Shape Geometry Model: Earth; Spherical globe. 

o Atmospheric State Model: Earth; 1976 Standard earth density, speed of 
sound, and temperature model (Z% accuracy to 1000 KM). 

o Atmospheric Kinematics Model: Earth; Rotating atmosphere (with local wind 
perturbations currently zero). 

o Magnetic Field Model: Earth; Tilted, shifted, vector dipole. 

o Inertial Frame Model: Planet centered inertial point, with inertial frame 
aligned to planet-fixed frame at zero time. 


Entity Attribute Environment 


As delivered, all TOSS objects can experience simple aerodynamic drag. Tethers 
experience distributed aerodynamic lift and drag. Tethers carrying electric current 
experience electromagnetic forces. 

TOSS is designed to facilitate incorporation of any degree of entity attribute 
simulation. 


0. SYSTEM MODELS 

The design philosophy of TOSS has been to provide a useful array of built-in system 
simulation features such as data driven scenarios for: control forces and moments, 
tether deployment, and electromagnetic power generation; as well as default 
aerodynamics options; etc. In addition, TOSS supports arbitrarily complex 
simulation of mass properties, control systems, aerodynamics, tether deployment, 
and power generation, etc. through its documented user-interface data structures, 
modularized code, and logical hooks which invite and assist in user modification. 

Of course, when TOSS is incorporated into a host simulation, all the system models 
present in the host then function in the tether environment provided by TOSS. 
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E. L1MITHTI0NS 


The following summarizes the currently known limitations to the use of 
GTOSS/TOSS (also see section below entitled: What should be done next). 

a. Tether Frame Definition: The orientation of the Tether Frame is undefined if 
attach point line-of-sight becomes exactly perpendicular to an associated orbital 
plane. Near this state, frame orientation rates can become large, inducing 
large apparent rates of change of finite tether coordinates. This can be avoided 
in the Point synthesis model by integrating coordinates in the inertial frame 
(thus using the tether frame for interpretation only). To date, this has not 
been a practical restriction (due to the nature of engineering applications); If 
required, this restriction can be removed. 

b. Modal Synthesis Finite Tether Model: This model is only valid during motions 
for which the distance between attach points is greater than the deployed 
tether length (a state of intrinsic tension). Furthermore, cases in which 
cyclic slack/taut states are a significant element of behavior may not be 
simulated well. In short, while the Modal synthesis model has some 
advantages, the Point synthesis (bead) model is significantly more robust and 
should be used to establish truth datum. 

c. Stabilized Gravity Gradient Initialization: Currently this feature applies only to 
simple chains, limited to 3 objects and 2 tethers (as a mixture of massless and 
Point synthesis models). Multiple disconnected chains are allowed. 

d. Certain Environmental Effects (for example, solar pressure effects) are not 
incorporated into TOSS. 


F. URL I POTION MDMflflS 

Validation of TOSS/GTOSS involves three distinct areas: Classical techniques (for 
those cases which are simple enough to be described by classical closed form 
solution); Comparative techniques (for those cases which defy classical 
substantiation); and Official techniques (to verify site installation and validate 
evolutionary changes to GTOSS). 


Classical Uertflcatlon 

Offical solution verification of TOSS has been accomplished from many directions. 
First, the simulation of the rigid body TOSS objects are verified via classically 
known solutions to Euler's rotational equations and Newton's law. Overall 
translational dynamics is further verified against classical Keplerian motion. 
Massless tether dynamics are verified against known gravity gradient as well as 
bolo type motions. Finite tether wave propagation and shape verification has also 
been accomplished against classical string theory. 
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Comparative Uerification 


Finite tether dynamics have been verified by comparing both the TOSS Modal 
Synthesis (MS) and Point Synthesis (PS, ie. bead model) against each other and 
against a bead model independently developed by NASA JSC. These comparisons have 
addressed aerodynamic response, wave propagation, and slack/taut behavior. 
Electrodynamic finite tether response has been officially compared only internally 
to TOSS (between the MS and PS models). 

There are at least 5 known, actively used, installations of GTOSS. When GTOSS is 
installed, users invariably compare its results to independent tether solutions 
previously verified by the installation. To date, there are no unexplained anomalies 
in result comparisons of this type. 


Installation Delineation 


Delivered with GTOSS are 18 different input run decks (along with corresponding 
official results) which test all aspects of GTOSS. A user site compares the output of 
the newly installed GTOSS to these official results to verify site installation. 


6. IDHHT SHOULD BE DONE NEXT 


The following features are either planned, or recommended for future GTOSS/TOSS 
development: 

1. Non-uniform point spacing for the Point Synthesis (PS) finite tether model: 
This will allow more efficienct use of degrees of freedom for solving certain 
type finite tether problems. 

2. Non-uniform material properties for the PS finite tether model: This will allow 
simulation of tethers which are purposely constructed of different materials as 
a function of length. 

3. Auto- transition (on user defined criteria) from finite to massless to finite 
tether models: This will allow full mission simulation continuity without the 
large computation overhead associated with very short tethers. 

4. Improved aero force model for finite tethers: The current model does not 
represent the consensus standard for distributed air loads on tethers 

5. Flexible boom attachment simulation. This will allow a certain amount of 
attach structure flexibility without full involvement in simulating body 
flexibility of a TOSS object. 

6. While the latest version of TOSS reflects an emission-end-sensitive plunging 
aspect of tether deployment (under small strain), the author does not admit to 
knowledge of an ultimate expression for deployment kinematics or dynamics. 
TOSS will be continually improved in this area as understanding is gained. 
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H. £M £ STUDY EHRMPLES 
Examples of Host/TOSS Integration 


There are two different instances of TOSS having been successfully introduced into 
a host simulation environment: the first of these is GTOSS (described above), the 
second is called STOCS (Shuttle Tethered Object Control Simulation). The host 
simulation for STOCS is a full engineering fidelity flight control simulation of the 
Orbiter. STOCS is being used to perform mission verification tasks for the TSS 
experiment (under the responsibility of NASA JSC). STOCS is an excellent example 
of complex control systems (TSS on-board control) becoming associated with a TOSS 
object (which represents the TSS), as well as the introduction of specialized tether 
deployment systems (TSS deployer) into TOSS. 


Examples of TOSS/GTOSS Application 

TOSS has been used to study enumerable engineering applications of tethers. Some 
of these are: 

1. TSS mission study (STOCS/TOSS, 2 rigid-bodies, both massless and bead model 
tethers). 

2. A spinning, orbital station ( 6 rigid-bodies, 15 massless tethers). 

3. Gravity gradient/Gyroscopic orienting spinning dumbell (2 particles, 1 massless 
tether). 

4. Electrodynamic day/night power gcneration/orbital boost with tethered counter 
balance (3 particles, 1 bead model and 1 massless tether), 

5. Real-time Shuttle Engineering Simulator (SES) verification (comparison runs 
made with both GTOSS and STOCS). 

6. Planetary exploration maneuvers using a slingshot mechanism. 

7. Electrodynamic pulse maneuvers (2 particles, 1 bead model tether). 

8. Space Station docking devices (3 particles, 2 massless tethers). 

9. Orbiting, spinning carousel (3 rigid-bodies, 1 massless, 1 modal synthesis, 
and 1 bead model tether). 

10. Gravity gradient stabilized orbiting platform (3 rigid-bodies, 1 modal synthesis 
and 4 massless tethers). 

11. Simulated bead model by chain-connecting 9 TOSS rigid-bodies with 8 massless 
tethers (for bead model verification study;. 

12. Comparative solution verification studies between GTOSS and an independent 
bead model simulation (wave propagation, aerodynamic response, symmetrical 
slack/taut gravity gradient behavior of a system exhibiting TSS physical 
properties) 
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| GTOSS TERMINOLOGY || 

TOSS II? Tethered Object Sub-System 

GTOSS ItF 3 Generalized Tethered Object 

Simulation System 

nmm KS 3 Result Data Base sub-system 

nmm Display print ROB post-processor 
CTFGD§)S§ CF 3 Cbart/Graphics ROB post processor 
imm kf* i mi graphics ROB post processor 
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INTERFACE CONCEPT 





SVSTEM 

INTERFACE 



INTERFACE DATA STRUCTURE 

• REF. PT. STATE UJR/T INER. PT. 

• ATTACH POINT KINEMATIC STATES 

• ATTACH POINT FORCES/COUPLES 


cf- No Orbital State Assumptions 
No Small Motion Assumptions 
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GTOSS OPERATION 




GTOSS Input 
file INDATA 


means 
HSCII file 



Optional CRT 
interactive input 

Optional CRT 
run Monitoring 


Quicklook output 
file OUTDATA 


Results Data Base 
file set run / 

i 

Results Data Base 
file set run 2 


Results Dat8 Base 
file set run N 


HRCHIUED ROB’S 


DTOSS Input 
file INDIS 


DTOSS 


Multi -Page Print 
Facility output 
file OUTDIS 


Optional CRT 
interactive input 

Optional CRT 
run Monitoring 


(Similar RDB 
processing 
for CTOSS 
and ITOSS ) 
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9 Bodies (3 or 6 DOF) 


25 Different Tethers 


8 Tether attachment points per body 


Totally General Connectivity 


Tether models, your mined choice of: 



Massless 

Modal Synthesis (3-D) 


Up to 15 Modal Coordinates (Legendre) per oh/s 
Up to 30 Generalized Force eualuation interuals 
Tension uia strain or Lagrongion mu/tipiers 



Point Synthesis (3-D) 


Up to 50 collocation points per tether 

3 DOF per collocation point 

Tether seuer (on time) or break (on tension) 


Data-driuen, arbitrarily assignable scenarios 

5 length-rate deployment scenarios 
5 tension control deployment scenarios 
5 pouter profile (amp limited) generation scenarios 
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Input to all TOSS enuironment routines: 

1. Fidelity leuel flag 

2. Simulation Time 

3. Position in Planet-fined frame 


Inertial Fram^Model | EFTEI, EITeT 

To eualuate this enuironment, use standard routine 


Grauity Model | GRRU 
GlobeShap^Mode^j EE0D~ 
Magneti^neldModel | GRUSS 
fltmospherl^tate Model j) nTM0S 


Atmospheric Kinematics Model | WINDS 
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Tether-Frame is Un-defined uihen 
line of attach points is 90 degrees 
out of the orbital plane 


$ Modal Synthesis model ualid only 
for a state of intrinsic tension 


*=> Modal Synthesis model dubious 
for cyclic slack- foot states 

9 Stabilized Grauity Gradient start-up 
ualid only for simple chains of up to 
3 bodies and 2 tethers (mixed bead 
and/or massless) 
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MMrVHrVHrVH J lMr4MrVHrVHrVHrV^ 


CylCLRSSlCRL UERIFICRTIDN 


♦ Keplarian/Neiotonian behauiour 


• Classical String Theory 


Cj^|COMPRRRTIUE UERIFICRTION 


Participants: 

• JSC deueloped bead model 

• GTOSS bead model 

• GTOSS modal synthesis model 


Study parameters: 

■ TSS Type Parameters 

• Hero Response 

■ Transuerse Ulaue Response 

• Symmetrical, Un-forced Response 


EP’IOFFICIRL UERIFICRTION 


K^IUN-OFFICIRL UERIFICRTION 
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TOSS/GTOSS RPPLICRTION 

• TSS/Orbiter Compatibility (2RB, 1 TH) 

• Spinning, Orbital station (6RB, 15TH) 

• Grauity gradient/Gyro dumbell (2 P, 1 TH) 

• Day/Night electro pivr gen (3 P, 2 TH) 

• SES uerification (GTQSS/STQCS) 

• Planetary exploration studies 

• Electro pulse maneuvers (2 P, 1 th) 

• Space Station docking deuice (3 P, 2 TH) 

• Orbiting spinning carousel (3 RB, 3 TH) 

• Gravity gradient platform (3RB, 5 TH) 

• 9 Body equivalent bead model (8 TH) 

• Uerification studies (20 - 50 beads) 
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WHIRLING DERVISH 
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| FUTURE GTOSS PLANS [ 

C^> Non-uniform Point Spacing 

C^> Non-uniform Tether Properties 
t£> fluto-phase transition 
Cj>lmproued aero-force model 
C^> Flexible boom simulation 

l^>lmproued deployment fidelity 
C^> Expert, Friendly User interface 
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BEAD MODEL V8 MODAL SYN AERO RESPONSE 



OJO 0.2 0.4 0* 0J8 1 JO 


NORMALEED TETHER LENGTH (300k FT) 


h 


( 

a 

2 

ill 


BEAD MODEL WAVE PROPAGATION (48 Beads) 
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(snon) JU3 tauai miuM/winuMi 


DRY/NITE 


6ENERHTI0M (65k LENGTH) 






